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Abstract: To ensure the privacy of users in transport 
systems, researchers are working on new protocols pro¬ 
viding the best security guarantees while respecting 
functional requirements of transport operators. In this 
papeip~| we design a secure NFC m-ticketing protocol 
for public transport that preserves users’ anonymity 
and prevents transport operators from tracing their cus¬ 
tomers’ trips. To this end, we introduce a new practi¬ 
cal set-membership proof that does not require provers 
nor verifiers (but in a specific scenario for verifiers) to 
perform pairing computations. It is therefore particu¬ 
larly suitable for our (ticketing) setting where provers 
hold SIM/UICC cards that do not support such costly 
computations. We also propose several optimizations of 
Boneh-Boyen type signature schemes, which are of inde¬ 
pendent interest, increasing their performance and effi¬ 
ciency during NFC transactions. Our m-ticketing proto¬ 
col offers greater flexibility compared to previous solu¬ 
tions as it enables the post-payment and the off-line val¬ 
idation of m-tickets. By implementing a prototype using 
a standard NFC SIM card, we show that it fulfils the 
stringent functional requirement imposed by transport 
operators whilst using strong security parameters. In 
particular, a validation can be completed in 184.25 ms 
when the mobile is switched on, and in 266.52 ms when 
the mobile is switched off or its battery is flat. 
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1 Introduction 

Near Field Communication (NFC) is a highly- 
practical emerging technology ^7}. Indeed, NFC- 
enabled smartphones are being used in several domains, 
such as payment m, access control |19] and ticket¬ 
ing )16| . In the following, we focus on mobile ticketing 
for public transport. Such a ticketing system is oper¬ 
ated by a transport authority representing the trans¬ 
port service provider, and it usually consists of three 
phases [39]. First, the user registers {Registration). Sec¬ 
ondly, the user obtains the product (a set of m-tickets) 
to be used {Provisioning). The last phase is the Val¬ 
idation, during which an m-ticket is validated by the 
transport authority using the NFC connection of a mo¬ 
bile phone. During this phase, the m-ticketing system 
must ensure the integrity and authenticity of the m- 
ticket. Another important aspect is that a network con¬ 
nection m is sometimes required, either for the val¬ 
idator gate or for the smartphone itself. Moreover, the 
validation is subject to a hard time constraint imposed 
by the transport operators |32| : the m-ticket validation 
must occur in less than 300 ms. 

In the literature, many proposed solutions did not 
consider the security aspects. Even when security is¬ 
sues are addressed, the concept of user’s privacy, that 
is users’ anonymity and users’ trips unlinkability with 
respect to the transport service provider, is often over¬ 
looked [221149] . Some recent works dniiiii have shown 
a special interest in users’ privacy. Although they man¬ 
aged to ensure user’s anonymity, these solutions suffer 
from privacy weaknesses. 

In this paper, we propose a new cryptographic pro¬ 
tocol for m-ticketing that provides strong authentica¬ 
tion, anonymity, and unlinkability properties, whilst re¬ 
maining efficient when implemented in constrained en¬ 
vironments such as SIM cards. 
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Towards this goal, we also make various crypto¬ 
graphic optimizations. In particular, we present a new 
efficient set-membership proof enabling a prover to 
prove, in a zero-knowledge way, that his secret belongs 
to a given public set. Unlike previous constructions, this 
proof does not require pairing computations, especially 
on the prover side, which are quite costly, in the or¬ 
der of seconds, e.g. for the following microprocessors: 
17.9s on an ATmega |l8], 2.5s on a Philips HiPerS- 
mart™MIPS [TH], 1.9s on an MSP430X [H]- We also 
propose several optimizations of Boneh-Boyen signa¬ 
ture schemes. These results are of independent inter¬ 
est and increase the performance and efficiency of BB- 
signatures. 

Based on these cryptographic primitives, our m- 
ticketing protocol enables to securely validate an m- 
ticket without disclosing any personal information to 
the transport operator, even if the latter is malicious. 
We push forward a strict privacy requirement when us¬ 
ing one of the numbered m-tickets: for example, if the 
user uses the m-ticket number 3 from the set [1..10], the 
transport operator will only be able to check that the 
used m-ticket is one among the ten m-tickets [1..10]. 

We implemented our system on a standard NFC 
SIM card. To the best of our knowledge, this is 
the first implementation of efficient and practical set- 
membership proofs and BB-signatures on SIM cards. 
The entire validation process can be performed without 
any connection to a back-end server or computations 
delegation to the smartphone hosting the SIM card. 
This avoids any tracking of the user by a malware in¬ 
stalled in the smartphone. We also show that the valida¬ 
tion process occurs, on average, in 184.25ms when the 
mobile is switched on and in 266.52ms when the mo¬ 
bile is switched off or its battery is flat (battery-Off). 
Moreover, we show that our protocol supports the post 
payment approach (which provides more flexibility) and 
give countermeasures to detect any misuse of the service 
owing to the regular reports of unused m-tickets. 

The paper is structured as follows. Section dis¬ 
cusses related work on privacy-preserving m-ticketing 
schemes. In Sectionwe detail the framework of our m- 
ticketing protocol. Then, we introduce in Section]^ our 
assumptions and the desired security, privacy and func¬ 
tional requirements that an m-ticketing system should 
fulfil. In Section we describe the cryptographic as¬ 
sumptions and building blocks required for the sequel. 
We introduce our new set-membership proof in Section]^ 
and our m-ticketing protocol in Section Section 
gives the security proofs. In Section we present our 
implementation before concluding in Section [Tol 


2 Related work 

Heydt-Benjamin et al. were the first to propose a cryp¬ 
tographic framework for transport service )33| . They 
discuss the challenges that a privacy-preserving transit 
system should solve. Using cryptographic transit tickets 
should not disable basic capabilities like cloning detec¬ 
tion, virtual ticket backups or transfers, ticket revoca¬ 
tion. The efficiency of the use of a virtual ticket, espe¬ 
cially over the air, is also important. Later, many ap¬ 
plied m-ticketing solutions have been proposed 0 [M 
[22l [35l HD 051 0H]. However, each proposal has some 
limitations that this paper tries to solve. We briefly de¬ 
scribe these limitations in this section. 

First, the RSA based m-ticketing solution proposed 
by Ekberg and Tamrakar |22l 02] , the RFID e-tickets 
proposed by Sadeghi et al. 03] and the ticketing so¬ 
lution proposed by Blass et al. [5] only protect user’s 
privacy with respect to outsiders and not the transport 
authority. The transport authority is considered honest 
which is not anymore a reasonable hypothesis. 

Second, the most recent protocols that include the 
expected level of privacy by protecting users’ privacy 
even against the transport authority still have some ef¬ 
ficiency problems. For instance, the BBS based protocol 
proposed by Isern-Deya et al. [35] validates a ticket with 
a duration of few seconds, even if the implementation 
has been done on a smartphone. Some recent solutions 
were close to find the right balance between efficiency 
and users’ privacy. Derler et al. proposal [1^ provides 
anonymous tickets but users’ trips are still linkable. 
Rupp et al. proposal jH] provides a privacy preserving 
pre-payment protocol with refund for public transport 
with a refund verification procedure with a too high 
cost for constrained devices. Removing this verification 
makes possible to use the protocol, but it also enables 
a malicious transport authority to link users’ trips, as 
detailed in Appendix 

Our m-ticketing protocol tries to fill the remaining 
gap between efficiency and strong privacy. It can be used 
in very constrained devices, like SIM cards and offers a 
high level of privacy. 

3 Framework of the protocol 

In privacy-preserving m-ticketing system, we consider 
three different entities. The user (U) is the owner of an 
NFC-enabled smartphone and wants to use the trans¬ 
port service. The transport authority (TA) is the man- 
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ager of the transport service. Additionally, we consider 
a third actor which is a revocation authority (RA). It 
can revoke m-tickets and users’ anonymity, and is com¬ 
pletely independent of the transport authority. This role 
may be split between several authorities in such a way 
that they should all agree and cooperate before recov¬ 
ering the identity of an m-ticket holder. 

An m-ticketing system consists of six different 
phases in our protocol. (1) The m-ticketing system pa¬ 
rameters and keys are initialized during the initializa¬ 
tion. (2) The registration phase enables a user to regis¬ 
ter to the transport service. (3) In the permission token 
request phase, a user gets a permission token allowing 
him to generate maxucket m-tickets. (4) The validation 
phase consists in generating and validating an m-ticket. 
(5) The revocation phase enables to retrieve the iden¬ 
tity of a user who generated a given m-ticket and the 
m-tickets obtained by a given user. Finally, (6) the re¬ 
porting phase enables a user to report his usage (i.e. 
the m-tickets that he did not use) to the transport au¬ 
thority that can detect any duplication of m-tickets (i.e. 
m-tickets that have been validated several times). In 
the sequel, these phases are modeled with various algo¬ 
rithms and protocols executed by the above entities. 

Initialization. 

Setup(l^): This probabilistic algorithm outputs pp 
a description of the system parameters. We assume that 
pp are implicit to the other algorithms, and that they 
include A, the security parameter, and maxucket, the 
number of m-tickets that each book/set of m-tickets 
contains. They are also an implicit input to the adver¬ 
sary, we will then omit them. 

Keygen(pp): This probabilistic algorithm outputs 
the two following secret/public key pairs: {rsk,rpk) for 
the revocation authority and {tsk, tpk) for the transport 
authority. The system public key gpk is eventually set 
as {pp, tpk, rpk). 

Registration. 

UKeygen(gpA:, IDu): This probabilistic algorithm 
outputs a secret/public key pair {usk,upk) for a user 
identifier IDjj. 

Register{U{IDu,upk),TA{DBiiEG))' This is an in¬ 
teractive protocol between a new user that takes as in¬ 
put his identity I Du and his public key upk, and the 
TA that takes as input the database DBreg where the 
identifiers of the registered users will be stored. If TA 
accepts the protocol, the user’s identity and public key 
are stored within DBreg- 

Permission token request. 

TokenRequest(U(tipA:, gpk), TA{tsk, gpk, DBjieg))'- 
This is an interactive protocol between a user that 


takes as input {upk, gpk), and the TA that takes as in¬ 
put {tsk, gpk, DBreg)- If the user accepts the protocol, 
his output is a permission token r that will enable him 
to generate/validate a set of maxucket m-tickets. If TA 
accepts the protocol, its output is a transcript view of 
the protocol. 

Validation. 

GenTicket( 5 pfc, t): This probabilistic algorithm 
takes as input a user’s permission token t and outputs 
an m-ticket Tickk with a serial number B^ such that 
k e [l..maxticket]- 

ValidateTicket(gpfc,Ticfefc): This deterministic al¬ 
gorithm takes as input a ticket Tickk- If Tickk is valid, 
it outputs 1 (otherwise 0) and Tickk is stored within 
the database DBusedTickets that will be used to detect 
the m-tickets that have been used several times. 

Revocation. 

IdentUser(rsfc, DBeeg, Tickk): This deterministic 
algorithm takes as input the private key rsk, the 
database DBreg and a valid m-ticket Tickk- R out¬ 
puts the identifier I Du of the user who obtained Tickk- 
If I Du does not belong to DB^eg, h outputs ±. 

IdentTicket(rsfc, view, I Du): This deterministic al¬ 
gorithm takes as input the private key rsk, a user’s 
identifier I Du and a transcript view of an execution 
of TokenRequest with this user. It outputs all the m- 
tickets that can be generated from the token obtained 
after the execution of the TokenRequest protocol that 
led to view. 

Reporting. 

ReportTicket(T): This algorithm is executed by a 
user with his permission token t. The user generates all 
the unused m-tickets and collects them in a usage report 
R. R is then sent to the transport authority. 

ldentDwpl±ca.te{Bk, DBuaedTickets): This determin¬ 
istic algorithm takes as input Bk the serial number of 
a valid m-ticket Tickk and DBusedTickets, and outputs 
the number of occurrences of Bk in DBusedTickets- 


4 Requirements 

In this section, we first describe our trust assumptions. 
Then, we detail the requirements of our m-ticketing sys¬ 
tem. We consider two types of requirements, functional 
requirements, which are “efficiency” and “versatility” 
and security and privacy requirements, which consist 
in “correctness”, “unforgeability”, “unlinkability” and 
“non-frameability”. 
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4.1 Trust assumptions 


At the user’s side, we consider an untrusted mobile plat¬ 
form (smartphone) with an incorporated trusted secure 
element. We use a SIM card as a tamper resistant se¬ 
cure element since it could be certified EAL4-I- |24) . 
Using a SIM card will ensure the integrity of the im¬ 
plementation. Indeed, the m-ticketing cardlet manages 
the cryptographic credentials of the m-ticketing applica¬ 
tion and executes required cryptographic computations 
without delegating any of them to the smartphone. Con¬ 
sequently, if the mobile application is compromised, the 
security will not be impacted because all the sensitive 
data and credentials are stored and managed in the SIM 
card. If the SIM card gets compromised, we planned 


countermeasures (cf. Section 7.4.21. 


4.2 Functional requirements 

4.2.1 Efficiency 

M-ticketing systems must fulfil functional requirements 
imposed by transport operators |32], in particular the 
validation of an m-ticket must be performed in less than 
300ms. We must consider that a SIM card has limited 
computation capabilities. In particular, pairing APIs are 
not available on current SIM cards. 


4.2.2 Versatility 

The mobile phone and the validator cannot be assumed 
to be connected to a back-end server during the vali¬ 
dation phase. This enables the user to use an m-ticket 
in any kind of situation, especially in areas with low 
connectivity, e.g., underground, or if the battery of his 
mobile is flat. Moreover, the m-ticketing system must 
support the post-payment mode, i.e., charged later (af¬ 
ter its use). 


4.3 Security and privacy model 

Besides the correctness propertTl (which is obvious), 
we formally define three security and privacy properties 


2 Informally speaking, our protocol is correct if (1) a valid permis¬ 
sion token enables to generate valid m-tickets, (2) honestly generated 
m-tickets are accepted, (3) a validated m-ticket enables revocation 
authorities to identify the user who generated it and (4) revoca¬ 
tion authorities can retrieve all the m-tickets generated by a given 
registered user that obtained a valid permission token. 


of our m-ticketing protocol in which the attack capabil¬ 
ities of a probabilistic polynomial time adversary A are 
modeled by providing him access to some oracles. In the 
sequel, 777/ will denote the set of honest users and A4U 
the set of corrupted users. We assume that A receives 
all the exchanged messages in our system. A acts as an 
active adversary as regards to the messages issued by 
malicious users and as a passive adversary with respect 
to honest users. 

O Register HU is an oracle that will be used by 
an adversary in order to register honest users. By 
calling this oracle with I Du as argument, the adver¬ 
sary adds a new user. The oracle runs {upk, usk) -u- 
UKeygen(g'pfc, I Du) and adds IDu (along with upk) to 
the set 'HU. The private key usk is kept secret and pub¬ 
lic key upk is returned to the adversary. 

ORegisterMU is an oracle that will be used by an 
adversary in order to register malicious users. The ad¬ 
versary calls this oracle with argument the identifier 
IDu of a user and sets his public key to upk and his 
private key to usk. The identity IDu (along with upk) 
is added to the set A4U. 

OCorruptUser is a user secret key oracle enabling 
the adversary to obtain the private key usk of a user 
IDu £ RU. The oracle transfers IDu to A4U and re¬ 
turns usk. 

OTokenRequestu is an oracle that runs the user’s 
side in the TokenRequest protocol. This oracle will be 
used by an adversary playing the role of a malicious TA. 
The adversary gives to the oracle an identity IDu of an 
honest user and his public key upk. The adversary is 
then given a transcript view of the protocol. 

OTokenRequestr is an oracle that runs the trans¬ 
port authority side in the TokenRequest protocol. This 
oracle will be used to simulate the execution of the pro¬ 
tocol between a user (corrupted or not) and an honest 
TA. 

OGenTicket{IDuTview) is an oracle that takes as 
input the identifier IDu of an honest user and a tran¬ 
script view of an execution of the TokenRequest proto¬ 
col with this user and outputs an m-ticket Tick^ using a 
fresh index k that has not been used in a previous query 
of OGenTicket on IDu and view. The oracle records 
{IDu, Tickk) in a list Set 

OIdentTicketT{IDu,view) is an oracle that takes 
as input the identifier of a user IDu and a transcript 
view of an execution of TokenRequest with this user 
and outputs all the m-tickets that this user is able to 
generate. 
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1. pp ■<— Setup{l^)-, l-iU ■<— 0; ^AU ■<— 0; Set ■<— 0. 

2. (gpfc, fsfc, rsfc) •<—Keygen(pp). 

3. (Tickk) ^ A{gpk, tsk, rsk, DBreg^ DBjjsedTickets- 

ORegisterHU 1 O Register mu'> OCorruptUser, 

OTokenRequestu, OGenTicket, OReportTicket). 

4. If ValidateTicket(gpfc, Tzcfcfe) = 0 or IdentUser(rs/c, 
DBEEGi'^'^^^k) =-l- then return 0. 

5. If IdentUser('rs/i;, Ticfc^) = IDu E "HU and 

(IDu, Tickk) ^ Set then return 1 else return 0. 


Fig. 1. Non-frameability security experiment 

OIdentUserT{Tickk) is an oracle that returns the 
identifier IDjj of the user who generated an m-ticket 
Tickk- 

OReportTicket{IDuview) is an oracle that takes 
as input the identifier I Du of an honest user and a tran¬ 
script view of a TokenRequest execution with this user 
and outputs the set of unused m-tickets. For each un¬ 
used m-ticket Tickk, the oracle records {IDu, Tickk) in 
Set 

In the sequel, we denote by A{keys, DB: oracles) an 
adversary who receives the keys ^Aeys”. This adversary 
has only read access to the databases ^^DB” and can 
query the oracles “oracles”. 

4.3.1 Non-frameability 

Informally speaking, it should be impossible for any¬ 
one to falsely accuse an honest user of having spent an 
m-ticket. We formally define the non-frameability ex¬ 
periment Exp^'^^“(l^) in FigureThe scheme is non- 
frameable, if for any probabilistic polynomial time ad¬ 
versary A, the probability 
Pr[Exp^'^’'“(l^)=l] is negligible. 

4.3.2 Unforgeability 

Informally speaking, it should be impossible for any¬ 
one (1) to validate more m-tickets than what he ob¬ 
tained i.e. an adversary who retrieved N tokens r {N 
sets of maxticket m-tickets) should not be able to gen¬ 
erate more that N * maxucket m-tickets; (2) to vali¬ 
date m-tickets such that the algorithm IdentUser re¬ 
turns _L, i.e., an identifier IDu that doesn’t appear in 
DBfiEG- We formally define the unforgeability experi¬ 
ment Exp“Wor9(iA)in Figure^ The scheme is unforge- 


1. pp <— Setup{l^)-, 'HU •<— 0; MU •<— 0. 

2. {gpk,tsk,rsk) Keygen(pp). 

3. i{Tickiyj'z[,{Ri}lz{) •(- A{gpk: ORegisteruu, 
ORegisterMUl OCorruptUser^ OTokenRequestj'^ 
OGenTicket, OReportTicket). An Ri corresponds to a 
“usage report”, i.e. a set of unused m-tickets. 

4. Let DB be an empty database. 

5. For j from 1 to / do {If ValidateTicket(pp/c, Tfc/c^ ) then 
store Tickj^ in DB}. 

6. For i from 1 to / do {Validate the m-tickets of the report 
Ri and store valid unused m-tickets in DB}. 

7. For all Tick^ in DB do {b = IdentDuplicate(.B^, Z).B) 
where B^ is the serial number of the m-ticket Tick^ 

If b>l, then delete all the duplicates of the m-ticket Tickk- 
If IdentUser(rs/c, DBreg^ Tickk) outputs _L then return 1 
and aborts.}. 

8. If L, the number of m-tickets that remained within DB, is 
greater that N * maxucket {L > N * maxticket) where N 
is the number of calls of the oracle OTokenRequestx and 
max-ticket is the number of authorized m-tickets by token, 
then return 1 else return 0. 


Fig. 2. Unforgeability security experiment 

able if for any probabilistic polynomial time adversary 
A, the probability Pr[Expy-^°'^®(l^) = 1] is negligible. 


4.3.3 Unlinkability 

Informally speaking, it should be impossible, except for 
the revocation authorities, to trace the m-tickets ob¬ 
tained by a user, in particular: (1) to link m-tickets 
obtained during the permission token request phase to 
the validated/used ones; (2) to link two m-tickets val¬ 
idated by the same user or to decide whether two val¬ 
idated m-tickets have the same number/index or not; 
(3) to link validated m-tickets to non-used m-tickets re¬ 
ported by the user to the transport authority. For this, 
an adversary has full control over the transport author¬ 
ity (in particular it owns the private key tsk) and all the 
users except two honest users io and ii. The adversary 
can initiate the IdentUser protocol over any m-ticket 
and can get the user’s identity behind it, except for 
the m-tickets generated by io and ii. He can also ini¬ 
tiate the IdentTicket protocol for all the users except 
for io and ii. We define the unlinkability experiment 
Expj**-fc(lA) in Figure i The scheme is unlinkable if 
for any probabilistic polynomial time adversary A, the 
advantage = |Pr[Expy“’"*’-'’(e) = 

b] — 1/21 is negligible. 
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1. pp <— Setup{l^)\ VU <— 0 ; MU •(— 0 . 

2. (gpfc, tsfc, rsfc) <—Keygen(pp). 

3. (* 0 , fco: * 1 > ^l) <- -Aigpk, tsk, DBjieG, DBusf.^Tickets- 

ORegisteruu 1 O Register muOC orruptUser, 

OTokenRequestu ^ OGenTicket, OldentTicketT, 

OldentUserT, OReportTicket). 

4. If 20 G AiU or 21 G AfZY then output _L. 

5. (a) let 20 and 21 run the protocol TokenRequest and get 

the permission tokens ro and ri and output viewQ and 
viewi. 

(b) Tick^f^ ■<— GenTicket(ppfc, To) and 

Tickj^^_^ ■<— GenTicket( 5 'p/c, ri), with b G {0,1}. 

6. b' <- A{gpk, tsk, DBreg, DBusedTickets, Tickk., 

Ticki^-^_^-. ORegisterEUy ORegisterMUy OCorruptUser, 
OTokenRequestx, OGenTicket, OldentTicketT, 

OldentUserx, OReport Ticket), with j £ {0,1}. 

7. If OCorruptUser was requested on iq or ii, or 
OldentTicketT was requested on (io, viewg) or (ii, viewi) 
then output ±. 

8 . If OldentUserT was requested for Tickf^^ or Tickk-^_^ , out¬ 
put ±. 

9. If OReportTicket was requested for io or ii and io and ii 
did not validate the same number of m-tickets then output 

±. 

10. Return b'. 


Fig. 3. Unlinkability security experiment 

Remark: another basic requirement that our tick¬ 
eting system should fulfill is the traceability meaning 
that revocation should succeed in the face of attacks 
by malicious users. In fact, our formulations of unforge¬ 
ability and non-frameability capture this requirement. 
Indeed, an attacker who could produce a ticket which 
either (1) cannot be traced to a user or (2) identify 
an honest user who didn’t obtain this ticket, would ei¬ 
ther break the unforgeability requirement (1) or the non- 
frameability requirement (2). 

5 Cryptographic assumptions and 
building blocks 

In this section, we introduce the notations, definitions 
and cryptographic tools used in the description of our 
set-membership proof and m-ticketing protocol. 


5.1 Bilinear Maps 

We consider throughout this document, except when it 
is explicitly mentioned, bilinear maps e : Gi x G 2 —> Gt 
where all groups Gi, G 2 and Gt are multiplicative and 
of prime order p. The mapping e satisfies the following 
properties: 

V 51 G Gi, 32 G G 2 and a,be Zp, e{gt,gl) = 6 ( 31 , 52 )“*' 
For gi 7 ^ and 32 ^ IG 2 , 6 ( 31 , 32 ) 7 ^ Igt 
6 is efficiently computable. 

5.2 Computational assumptions 

Decisional Diffle-Heilman (DDH). For any multi¬ 
plicative group G of prime order p, the DDH assumption 
states that given a random generator g e G, two ran¬ 
dom elements 3 “, 3 *’ in G, and a candidate X G G, it is 
hard to decide whether X = 3 “*" or not. 

external Diffie-Hellman (XDH). Given three 
groups Gi, G 2 , Gt, and a bilinear map e : Gi x G 2 —> 
Gt, the XDH assumption states that DDH assumption 
holds in Gi. 

q-Strong Diffie-Hellman (q-SDH). The q-SDH 
assumption holds for some group Gi if it is hard, 
given ( 3 , gV, 3 *' ,..., 3 ^") G Gf+\ to output a pair 

q-Decisional Diffie-Hellman Inversion (q- 

DDHI). In any multiplicative group G of prime order 
p, the q-Decisional Diffie-Hellman Inversion assumption 
states that, given a random generator g e G and the 
values ( 3 , 3 “, 3 “ ,..., 3 “'') G G, for a random a e Zp 
and a candidate X G G, it is hard to decide whether 
X = 3 ^/“ or not. 

The Decisional Composite Residuosity As¬ 
sumption. There is no probabilistic polynomial time 
distinguisher for n-th residues modulo n^. In other 
words, there is no probabilistic polynomial time adver¬ 
sary that can distinguish § from Z* 2 , where § = {0 G 
Z* 2 , 33 G Z *2 : 0 = y^mod n^}. 

5.3 Zero-knowledge proof of knowledge 

Roughly speaking, a zero knowledge proof of knowl¬ 
edge, denoted ZKPK, is an interactive protocol during 
which a prover convinces a verifier that he knows a set 
of secret values {ai,a 2 ,... ,a„) verifying a given rela¬ 
tion 5R without revealing anything else. Such a proof 
will be denoted in the sequel POK{{ai,a 2 , ■■■ ,an) : 
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5R(ai, 0 ( 2 , ■■■, ctn))- A ZKPK should be complete (a 
valid prover is accepted with overwhelming probabil¬ 
ity), sound (a false prover should be rejected with over¬ 
whelming probability) and zero-knowledge (no in¬ 
formation about the secret is revealed). These ZKPK 
can be made non-interactive using the generic trans¬ 
formation introduced by Fiat and Shamir |25]. The re¬ 
sulting non-interactive proofs, sometimes called signa¬ 
tures of knowledge m, can be proven secure in the 
random oracle model of [3] (see [H]). Such a signa¬ 
ture of knowledge, for the relation 5R, will be denoted 
SOK{{ai,a2, ■■■, On) : 5R(ai, 02 ,... , On)) . 

5.4 Camenisch-Lysyanskaya signatures 

These signatures, proposed by Camesnich and Lysyan- 
skaya [10], are equipped with additional protocols. One 
of these protocols allows a signature to be issued on mes¬ 
sages that are not known by the signer, but for which the 
signer only knows a commitment. Informally, in a proto¬ 
col for signing a committed value, we have a signer with 
public key pfc, and the corresponding secret key sk, and 
a user who queries the signer for a signature. The com¬ 
mon input to the protocol is a commitment C, known 
by both parties, on secret values (a;i,a:: 2 , ■■■ ,Xn) known 
only by the user. At the end of this protocol, the user 
obtains a valid CL — signature = Sign{x\,X2, ■■■ ,Xn) 
and the signer learns nothing about (rci, X2, ■■■, Xn). 

Another protocol allows to prove knowledge of a sig¬ 
nature on a tuple of messages (xi, X2, ■■■, Xn) without re¬ 
leasing any information on the corresponding signature. 
Each message can either be revealed to the verifier, sent 
in a committed form, or it may be such that the verifier 
has no information on it. In particular, it is possible to 
prove the knowledge of a CL-signature on committed 
values. 

5.5 Set Membership Proofs 

A set membership proof allows a prover to prove, in a 
zero-knowledge way, that his secret lies in a given pub¬ 
lic set. Such proofs can be used, for instance, in the 
context of electronic voting, where the voter needs to 
prove that his secret vote belongs to the set of all possi¬ 
ble candidates. Recent propositions of set membership 
proofs ini [ 13 ] follow the same idea: a designated au¬ 
thority produces public signatures on each element of 
the public set d> (and only on these elements). The proof 
of knowledge of a secret a; G <1> consists in proving the 


knowledge of a (public) signature on the secret x (which 
will be only possible if x belongs to the set <1>) without 
revealing x or the used signature. Solutions in |121I13| re¬ 
quire the prover to perform pairing computations. How¬ 
ever, these cryptographic tools are not often convenient 
for many constrained platforms. 

5.6 Boneh-Boyen Signatures 

The signature scheme used by the designated authority 
(which could be the verifier) to sign each element of the 
set <1> is the one proposed by Boneh and Boyen (SHE]. 
Based on their scheme, which is secure under the q- 
SDH assumption, it is possible to prove knowledge of a 
signature on a message, without revealing the signature 
nor the message. 

5.6.1 Boneh-Boyen Signatures with pairings. 

Having a secret key g and two random generators gi , g 2 
of Gi , the signature of a message m G Zp is obtained by 
computing a = Given a bilinear pairing e, a 

signature cr of m is valid if e{a,Ygtf^) = e{gi,g 2 ), where 
Y = g 2 is the signer’s public key. 

5.6.2 Boneh-Boyen Signatures without pairings. 

Let G be a cyclic group with prime order p where the 
Decisional Diffie-Hellman (DDH) problem is assumed 
to be hard and gi, g 2 two random generators of G. The 
signer’s private key is y G Zp and its public key is K = 
92- 

Similarly to Boneh-Boyen signatures with pairings, 
the signature on a message m is the value A = 

This implies that = giA~‘^. Since we work in a group 
G not equipped with a bilinear map, the signer must ad¬ 
ditionally prove that the signature on m is valid, which 
is done by generating a ZKPK tt that the discrete loga¬ 
rithm of {giA~"^) in the base A is equal to the discrete 
logarithm of Y in the base 92 : SOK{y : Y = g\ K = 
giA~^'). Such a proof of equality of discrete logarithms 
has been introduced in El- Finally, the signature A on 
m is valid if the proof tt is valid. 

Theorem 1. The Boneh-Boyen (BB for short) sig¬ 
nature scheme without pairings is existentially unforge- 
able under a weak chosen message attack under the q- 
Strong Diffie-Hellman assumption, in the random oracle 
model. 
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Proof (sketch). Under the q-Strong DifBe- 
Hellman assumption, it is impossible to find a message 
m (which was not given to the signing oracle) and a 
value A such that A = as proved in O |3- 

Moreover, in the random oracle model, the proof of 
knowledge n is unforgeable 017], which concludes the 
proof. 

5.7 Threshold Cryptosystems 

The El Gamal cryptosystem [53] works as follows. Let 
G be a cyclic group with prime order p where the 
Decisional DifBe-Hellman (DDH) problem is assumed 
to be hard. The public key consists of the elements 
{gT,hT = g^), where gx is a random generator of G, 
and the corresponding private key is formed by xx G Z*. 
The El Gamal ciphertext of a message m G G is (Gi = 
i7t, C 2 = m X hx), where r G Z* is a random number. 
The decryption of the ciphertext (Gi,G 2 ) is obtained 
through the following computation: m = . The 

El Gamal cryptosystem is semantically secure under the 
DDH assumption. 

The Paillier cryptosystem [30] works as follows. Let 
o and b be random primes for which a,b > 2, a 7 ^ 
b, |a| = | 6 | and gcd{ab, (o — 1)(6 — 1)) = 1. Let n = ab, 
n = lcm{a—l, b—l), K = H”^ mod n, and gp = (1+n). 
The public key is pk = (n,gp) and the secret key is 
sk = (a, b). To encrypt m G Z„, the user chooses r G Z* 
and C = EncryptPaipk{m,r) = g'pv^ mod n^. The 
decryption algorithm is given by DecryptPaisk{C) = 
{[C^^mod n?) — l)/n mod = m. The Paillier 
cryptosystem is secure under the Decisional Gomposite 
Residuosity assumptiorj^ 

In a threshold version, the El Gamal public key and 
its corresponding private key [17] (resp. the Paillier pub¬ 
lic key and its corresponding private key [26] ) are coop¬ 
eratively generated by n parties; however, the private 
key is shared among the parties. In order to decrypt a 
ciphertext, a minimal number of t (the threshold) out 
of n parties is necessary. 


3 We use Paillier encryption scheme in our system in order to satisfy 
the unforgeability requirement even in a concurrent setting, where 
the adversary is allowed to interact with the transport authority, 
during the permission token request phase, in an arbitrarily inter¬ 
leaving (concurrent) manner (see 1341 b 


5.8 Pseudo-random Function 

A useful building block of our m-ticketing protocol is the 
pseudo-random function introduced by Dodis and Yam- 
polskiy pniE]. Their construction works as follows. Let 
G be a cyclic group with prime order p, gt a generator of 
G, s G Zp a private secret. The pseudo-random function 
(PRE for short) Fs takes as input a message k £ Zp and 
outputs Fs{k) = This construction is secure 

under the q-DDHI assumption in G. 


6 A new set membership proof 

In this section, we present a new set membership pro¬ 
tocol. Our set membership proof is a ZKPK which al¬ 
lows the prover to convince any verifier that the com¬ 
mitted integer k lies in the public discrete set d>. This 
ZKPK can be made non-interactive using the Eiat- 
Shamir heuristic and the random oracle model [25] . The 
commitment scheme that we use is the one proposed by 
Pedersen mi- 

Our set membership proof bears some similarities 
with the protocol proposed by Camenisch et al. 0. 
Yet, our set membership proof does not ask the prover 
(a SIM card and/or a smartphone in our setting) nor 
the verifier (in a specific scenario) to perform pairing 
computations. Our set membership proof is also more 
efficient and conceptually simpler than the recent one 
proposed by Ganard et al. at EuroPKI 2013 |12j . Their 
scheme which involves several verifiers, who share a de¬ 
cryption key, seems to be tailored to specific applica¬ 
tions such as e-voting where the verifiers (tallying au¬ 
thorities) own such a key to open ballots. 

Let Gi, G 2 and Gx be three (multiplicative) bi¬ 
linear groups of prime order p and a bilinear map 
e : Gi X G 2 —>• Gx- Let g,g\ and hx be three gener¬ 
ators of Gi and consider a generator g^ of G 2 . A des¬ 
ignated authority (which may or may not be the veri¬ 
fier) randomly chooses a value y G Z* (its private key) 
and publishes the corresponding public key Y = g^- 
After generating its key, this designated authority can 
issue BB-signatures on each element of the public set <I>. 
Let k denote an element of the set d> and Ak the BB- 
signature on the value fc, i.e., Ak = The set 

of all message-signature pairs {k,Ak), that we denote 
by is published by the designated authority, if will 
denote a hash function, for instance, SHA-256. 

In Figure]^ we propose a protocol enabling to prove 
that the value k committed by the prover in the com- 
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Prover 


Verifier 


Public input: public parameters, sets and 
Private Input: k 


Public Input: public parameters, sets $ and 

Private Input: y 


Pre-computations: 


Choose u £ "Z* and Compute: Com = 

Pick the valid BB-signature corresponding to the element k : 

Choose / E Z* and Compute (see remark 1): B = A^; Bi = B~^] D = B^g^ 
Choose fci, ^ 1 , ri £ Z* and Compute: Comi = g^^hl^ and Di = B^^ g^^ 


Real time computations: 


Compute: c = H{Com, B, D, Comi, Di, ch) 
Si = ki + c X k mod p; S 2 = ri c x v mod p; 

= li + c X I mod p; H 

n = Com, B, Z), si, S 2,53 _ 


'Choose ch E ! 


(A random challenge) 


Check that B 7 ^ 

If the verifier and the designated entity are the same entity, 
it implies that the verifier holds the private signature key y 
(First case). Hence the prover does not send the value D. 
The verifier can compute it: D = By and goes to (*) 

• Otherwise, if the verifier doesn’t know the private signature 
key y (Second case), then, it checks that e{D,g:^) = e(B^Y) 
and goes to (*) 

(*) Compute: C = g^^ Com~^ and D = B^^ g^^ D~^ 
Check that: c = H{Com, B, D, C, D, ch) 


Fig. 4. A new efficient set membership proof 


mitment Com belongs to the set <I> which comes down 
to proving knowledge of the BB-signature Ak- 

Remark 1: Proving knowledge of a valid BB- 
signature Ak = g^Av+k) value k committed in 

Com = gihx, without revealing neither k nor the 
signature and without using pairings on the prover’s 
side can be done as follows. The prover first random¬ 
izes Ak by choosing a random value I G Z* and com¬ 
putes B = Ak- Since Ak = g^Ay+^) implies that 
B = A{ = (£,*)i/(y+fe) and then that 5^+^= = gK It im¬ 
plies, if we note Bi = B~^ and D = B^ that D = Big''. 

As a result, in order to prove that the value k com¬ 
mitted in Com belongs to the set <I>, the prover just has 
to send B and D to the verifier and compute the fol¬ 
lowing ZKPK: n = POK{k,y,l : Com = Qih^ A D = 
Big'). The computation of the ZKPK n is described in 
Figure 

Upon receiving B, the verifier proceeds to the ver¬ 
ification. We distinguish two cases. In the first case, 
the verifier and the designated authority are the same. 
Thus, the verifier holds the private signature key y. Con¬ 
sequently, the verification of 11 occurs without requir¬ 
ing any pairing computations. This implies that our set 
membership proof does not require pairing computa¬ 
tions for either the prover or the verifier. In the second 
case, the verifier does not have the private signature key 
y of the designated authority. Then, the verifier needs 
to perform some pairing computations in order to verify 
n. Nevertheless, the prover still has no pairing compu¬ 


tations to perform. This is particularly interesting for 
the m-ticketing use case. 

Theorem 2. If the |<I>|—SDH assumption holds, 
then the protocol in Figure is a zero-knowledge ar¬ 
gument of set membership for a set <I>. The proof is in 
Appendix 

7 Our m-ticketing protocol 

This section begins with an overview of our protocol 
which main notations are summarized in Table be¬ 
fore moving to our m-ticketing protocol and its post¬ 
payment aspects. 

7.1 Overview 

We assume that m-tickets have a unique rate per area 
such as in Paris m, Berlin H] and Moscow under¬ 
grounds. The user can have different types of m-tickets 
sets such that every set is characterized by a rate, an 
area and the number of available m-tickets {maxucket), 
e.g., a set of 10 m-tickets valid in area 1 and the price 
of one m-ticket is 1.30€. 

As shown in Figure at the beginning, the user 
registers at the transport service. Then, he retrieves a 
permission token A from the transport authority. This 
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Gi.G2.Gt 

9’9o.9i.9t, 

9T.9u,h.G.H 

(xt, hr) 

((a, 6), {n,pp)) 
(7, {W,W')) 

(y,y) 

(xu,hu) 

A 

IDu 

Tickf^ 

Bh 

E 

n 

ch 

DBpEG 

BBuge.£Tickets 


Multiplicative groups of prime order p 
Generators of Gi 

EIGamal private and public keys of the revoca¬ 
tion authorities 

Pailler private and public keys of the revocation 
authorities 

BB-signature scheme private and public keys of 
the transport authority 

BB-signature private and public keys of the 
transport authority for set membership proof 
Private and public key of the user 
A permission token 
The identity of the user 
The fc*'* m-ticket 

The serial number of the m-ticket 
The EIGamal encryption of the user secret cor¬ 
responding to his set of m-tickets 
A proof (POK) 

A challenge 

The TA secure registration database 
A secure database where the TA centralises the 
used m-tickets 


Table 1. Notation used in the m-ticketing protocol 


token enables the generation of maxucket m-tickets (an 
m-ticket set). The token A is a BB-signature on a secret 
s known only by the user. The secret s identifies a type 
of m-tickets set. 

At the validation phase, the user authenticates the 
validator and sends an m-ticket Tickk'. {Bk, E,IV). Bk 
is a unique serial number of the m-ticket, E is an EI¬ 
Gamal encryption of < 71 , and If is a ZKPK. If proves 
that (1) the user has a valid BB-signature on s with¬ 
out revealing neither s nor the signature A, (2) E is an 
encryption of gf without revealing s and (3) k belongs 
to [l..maa;ticfcet] without revealing k. (3) is based on the 
new set membership proof of Section 

Finally, the user post-pays by regularly reporting 
unused m-tickets i.e. by revealing the unused m-ticket 
serial numbers B^ to the TA. This enables to detect 
any malicious behaviour, i.e., validating more m-tickets 
than what were obtained, without breaking the user’s 
privacy. Additional countermeasures allows to recover 
the user’s identity and retrieve his m-tickets, with the 
agreement of the authorities. 


7.2 Model 

Setup of public parameters. Let g, go, gi, gt, gr, gu, 

h, G, H be nine generators of Gi and < 72 , <73 two gener¬ 
ators of G 2 . The user’s SIM card will perform compu¬ 



Fig. 5. The m-ticketing protocol overview 


tations only in Gi (note that current SIM cards are not 
designed to handle pairing computations nor computa¬ 
tions in G 2 or Gt). 

Revocation authorities. The revocation author¬ 
ities set two pairs of keys: a private and public keys of 
the threshold EIGamal cryptosystem {pkuo, skua) and 
a private and public keys of the threshold Paillier cryp¬ 
tosystem {pkRp, skRp). 

We assume that the private keys are shared among 
the revocation authorities (e.g. using the technique pro¬ 
posed in [30] for El Gamal and in |26| for Paillier). In 
order to decrypt a ciphertext, a minimal number t (the 
threshold) of these authorities should cooperate. 

The public key, pkpc, consists of the elements 
{gr , hp = g^) , where gr is a random generator of 
Gi, and the corresponding private key, skpQ, is formed 
by Xt £ Let o and b be random primes for which 
a,b > 2, a ^ b, |a| = |6| and gcd{ab, (o — 1)(6 — 1 )) = 1 ; 
let n = ab, II = lcm{a — l,b — 1), K = 11“^ mod n, and 
gp = {1 + n); then the public key, pkpp, is {n,gp) and 
the secret key, skpp, is (a, b). 

Transport authority. The transport authority 
(TA) sets for each group, i.e. a type of m-tickets set, 
a key pair of the BB-signature scheme. The private key 
is a random element 7 G Z* and the corresponding pub¬ 
lic key is W' = g^ and W = gj- The transport authority 
sets another key pair of the BB-signature scheme which 
will be used for the “Set membership proof”. The private 
key is a random element y G Z* and the corresponding 
public key is E = S'!- 

User. The user owns a public/private key pair 
{xu G '^p.hu = gp^)- During the permission to¬ 
ken request, the user obtains from TA a token A = 
s is jointly chosen by TA and the user but 
is only known by the user (whereas both know r). 
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User 

Transport Authority 


Public input: The public parameters 

Private Input: xjj 

Public Input: The public parameters 
Private Input: , DBppQ 



Choose Si G Z*, j G]0,n[ 

Compute: Com = , Co = g^p mod 'n? 

„ „ . Com,III,Cn 

Hi = POK{si^j : Com = g^^ f\Co = gpj^ mod n^) -» Verify Hi 


Choose S2 G Z* and Let s = si -h S2 mod p, 
then Com X = gjigp = = g| = c 

Choose r £ Z* and Compute: A = 

A,r,g'!^ ,n2 

Verify 112 and Compute: «- and 112 = POK{'y ■ W = gg A A'*' = c X hA~^) 


c = =9l, g = Sign(xu, A, gl\ gl^) 

Compute: s = si -h S 2 


Verify p 

Save (A, Co, S 2 , c, /i) associated to (IDu ^hxj) in 
DBpEG 


Fig. 6. The protocol of the permission token request 


7.3 M-ticketing protocol 

Our protocol is divided in three phases: user registra¬ 
tion, permission token request and validation. The later 
includes the validator authentication and the m-ticket 
validation. 

7.3.1 User registration phase 

We denote by I Du a user’s identity and DBheg the 
database where the TA saves the identities of registered 
users. First, the user sends his public key hu and his 
identity IDu to TA. Then, he signs, using Schnorr sig¬ 
nature scheme H^] , a random challenge rc received from 
TA, using his private key Xu- If the signature is valid, 
TA saves the tuple {IDu, hu) in DBreg- Then, the user 
securely introduces his banking credentials in order to 
be subsequently charged. 

7.3.2 Permission token request phase 

The permission token request phase is detailed in Fig¬ 
ure A permission token {A = {g{h)^/^'^'^'^\r) con¬ 
sists of an (extended) BB-signature [TD] on s (the secret 
member group key only known by the user, whereas r is 
known by the user and TA). Thanks to his permission 
token, the user will be able to use maxucket m-tickets. 
The value of maxucket is set by TA and linked to the 
key pair ( 7 , W = g]) used by TA during the permission 
token request protocol. TA will use a different pair of 
keys for each possible value of maxticket, i-e., for each 
group associated to each type of m-tickets set. 


At the end of this phase, TA saves in DBreg the 
view {A, Co,S 2 , c, g) where Co is the Paillier encryption 
of si such that the secret s = si -|- S 2 and (c, g) are the 
commitment and signature by the user of his secret s. 

7.3.3 Validation phase 

In this phase, the validator is authenticated, the per¬ 
mission token is verified and finally the m-ticket is val¬ 
idated. 

Validator authentication. The validator authen¬ 
tication consists of a challenge / response protocol. The 
user sends a Random Challenge RCy to the validator 
gate. Upon receiving RCy, the validator replies with the 
RSA signature on a timestamp {TS) and the received 
challenge (we use a short public verification exponent 

V in order to have a fast verification in the SIM card). 
Then, the m-ticketing cardlet checks the received signa¬ 
ture. If it succeeds, the m-ticketing cardlet checks the 
validity of the permission token based on the timestamp 
(TS) sent by the validator. Indeed, if TS is lower than 

V {TS < V), the permission token is still valid. Then, 
the cardlet checks whether the number of used m-tickets 
reached max ticket, the number of authorized post-paid 
m-tickets. If a check fails, the m-ticketing cardlet aborts 
and the m-ticketing application displays a message to 
ask the user to renew the permission token. 

M-ticket validation. An m-ticket Tickk (indexed 
k) is characterized by a serial number Bk = 
along with an ElGamal encryption E = {Ci = gx,C 2 = 
gl X h^) of gf. To prove the validity of a m-ticket, the 
user must prove that: 










A Practical Set-Membership Proof for Privacy-Preserving NFC Mobile Ticketing 


12 


- k belongs to $ = [\..maxticket] using our new set 
membership proof (described in Section]^, 

- He knows a valid BB-signature A = on 

s (without revealing both s and the signature), 

- U is an encryption of g{. 

Therefore Tickt = {Bk,E,Il) where H = 
POK{k,a,s,r,A: = (3f/i)i/(^+’') A 

Cl = A C2 = 3i ^ A fc G [l..moa;ticfcet])- 

Remark 2: Proving the knowledge of a valid BB- 
signature A = (31/1)^/^'*'+'’^ on a value s, without reveal¬ 
ing s or the signature and without using pairings on the 
prover’s side can be done as follows: 

The prover first randomizes A by choosing a ran¬ 
dom value a £ h* and computes Bo = v4“. Since A = 
(3^/1)^/^^'+’') this implies that Bq = 
and then that: 

= gTh’^ ( 1 ) 

Let us note by B' = B^^ and C = Bq. From Q, we 
have: 

C = 3“" X /i“ X B'”' ( 2 ) 

As a result, in order to prove that he knows a BB- 
signature A on the value s, without revealing s nor the 
corresponding signature, the prover just has to send Bq 
and C (that he can compute using (§) to the verifier 
and prove that he knows the representation of C with 
respect to (31, h, B'): Bbb = POK{a, s, r :C = gf^ x 
/i“ X B’’"). The proof consists in Bq, C and Bbb (and 
no pairing computations are needed on the prover’s side 
to compute Bbb)- The verifier will have to check that 
Bo ^ 1gi, that C = Bq (via pairing computations or 
by using the key 7 if it owns this key) and that Bbb 
is valid. If all the verifications hold, the verifier will be 
convinced that the prover knows a valid BB-signature. 

As described in Figure]^ the validator verifies the 
proof n, saves the date and time of the operation DT, 
the serial number of the validated m-ticket Bfc, the El 
Gamal encryption E (of 31) and the proof H. These 
verifications can be done in two ways. In the first case, 
the validator holds the private keys 7 (the private key of 
TA) and y (the private key used during the set member¬ 
ship). Hence, he can perform the verification of H with¬ 
out executing any pairing computations. In such a case, 
the protocol is run without any pairing computations 
either on the user side (SIM card) or on the validator 
side. In the second case, the validator does not hold the 
private keys 7 and y. Therefore, in order to perform the 
verification of H, the validator would execute pairing 


computations. We still achieve our goal, i.e., no pairing 
computations at the user side (SIM card). 

We emphasize that owing to our improvements on 
Boneh-Boyen based Camenisch-Lysyanskaya signature 
scheme, all the computations (required to validate an m- 
ticket) are performed by the SIM card. We do not need 
to outsource part of the computations to the powerful 
but untrusted mobile phone. Consequently, the user’s 
privacy is ensured with respect to the smartphone itself. 
Even a compromised mobile, e.g. containing a spyware, 
cannot collect any information about our m-ticketing 
application computations. 

Theorem 3. The protocol in Eigurej^is a ZKPK 
of a permission token (A, r, s) and a value k such that 
Bk = k e [l..maxticket] and E = {Ci,C 2 ) is 

an El Gamal encryption of gf. The proof is detailed in 
Appendix 0 

At the end of a successful m-ticket validation, the 
validator sends {Bk,E,IVj to TA in order to be saved 
within a centralized and secured database DBjjsedTickets 
jointly with his identity IDy and the date and time of 
the transaction DT. In such a way, the TA will detect 
any malicious behaviour such that a multiple usage or 
cloning (cf. Section 7.4.21. 


7.3.4 Revocation 

We distinguish two levels of revocation: the user’s 
anonymity revocation and the m-tickets revocation. In 
the first case, the transport authority would like to get 
the user’s identity corresponding to a given m-ticket. In 
the second case, the transport authority would like to 
revoke all the m-tickets of a given user, e.g., upon the re¬ 
quest of the user further to the theft of his smartphone. 

In order to recover a user’s identity based on a used 
m-ticket Tickk = (Bfc,B,n), TA sends E to the re¬ 
vocation authorities. Together, the revocation author¬ 
ities decipher E and retrieve the commitment of s 
(3I). By using DBbeg the database of registered users 
and gf, TA will find the user’s identity in the tuples 
(A, Co, S 2 , c, g, I Du, hu)- 

In order to retrieve the m-tickets of a user based 
on his identity IDu', first of all, TA must find the tuple 
{A, Co, S 2 , c, g, IDu, hu) from DBreg such that IDu = 
IDu'- Then, TA sends Co (the Paillier encryption of 
Si) to the revocation authorities. Similarly to the first 
case, the revocation authorities decipher together C and 
retrieve si. Upon receiving si, TA computes s = S 1 + S 2 , 
hence, it can retrieve all the m-tickets (Bj, = 
of the user. 
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Validator 


M-ticketing cardlet 


Public Input: The public parameters, hT,W,Y. The 
sets and ^ 


Public input: The public parameters and the 
public keys of the revocation and transport 
authorities hx^W^Y. The sets = [l..maxticket] 
and = {-4i, A 2 ,where 
Ai = c,l/(!/+i) for i e $ 

Private Input: A = , k (the index 

of the ticket that will be used), s 

T> day: validity end date of the permission token 


Private Input: The private signature keys 7 and y (in 
some scenario) 


Pre-computations: 

Compute Bk = 

Choose a E Z* and Compute: Ci = g^, C 2 = x 


Computation of elements involved in the proof that the user knows a valid signature on s 
Choose a E Zp and Compute (see remark 2 ): Bq = B' = Bq^; C = gf^ x x B''^ 
Choose 'r2, r3, r4, ai, di, 61, oi, f, ti, f3, t4, fs, z/, d', f' E Z* 

Compute: T' = /3 = as; T" = ^ ar2{mod p); Com = 

Pick the valid BB-signature corresponding to the element k-. Ak = 

Choose I g Z* and Compute: B = A^; Bi = D = B^g^ 

Choose kiClAi £ Z* and Compute: Com\ = g^^h’^; Di = 

S = s + k] f = a + u; K = gtB-^ = ^ = C2Com = gl+^h^+^ = g(h^ 


Computation of the witnesses 

Compute: C[ = 9“^ ; C'^ = g^^ X ; R' = R" = 

C' = K' = sf; L' = gf X /if 

Real time computations 

Validator authentication 

Choose RCv ^ Check that the number 

of used m-tickets < maxticket 

Verify Signature's A ^-nd Check that TS < T> 


-» TS = getTimeStampO 

Compute: 

Signature fig 

- SignaturejiSAi the RSA signature on RCy and TS 


m-ticket Validation 

. .. ch 

Compute: c = H{C^C\,C2-> Bo,T\T",Com, B, « - Choose c/i E Z* 

D,K, R', R'',C',T^,Comi, Di, K', V, ch) 

Si = ki c X k mod p; S2 = ri + c x u mod p Check that B 7^ 

s^ = li c X I mod p-, uji = ai c X a mod p • If The validator holds the private signature keys y 

0)2 = di -\- c X s mod p-, cos = ti + c x r 2 mod p / and 7 (First case). Hence the prover does not send 

0 ) 4 , = hi + c X j3 mod p-, oj^ = ai + c x a mod p / the value D and C. The verifier can compute it: 

ojQ = t c X r mod p; ojg = ts c x rs mod p / ^ D = B^, C = B^. Then goes to (*) 

ojiQ = £5 + c X r 5 mod p; ojn = d' cx 5 mod p / ^ Otherwise, if the validator doesn’t know the private 

0)12 = /^ + c X / mod p / signature key y and 7 (Second case), then, check that 

Let E = (Cl, C 2 ) and the proof / e(D, 513 ) = e{B, T); e(C, g 2 ) = o{Bq, W) and goes to (*) 

n = {C,Bq,T' ,T" ,Com,c,B,D,si,S 2 ,sz, / (*) Compute: C = g{^ hf^ Com-^-, D = Bl^g^^D-^-, 

a;i,a;2,cJ3,t^4,t^5,^6,^8,W9,wio,^ii,a;i2) Ci = C 2 = g^^h^'^C-^-, R' = G^‘^H^^T'-^- 

C' = g^^^h^^B'^^C-^; R" = T'^^ 

f4 = a^4H^i0rpff-c. K' = 

L' = 

Check c = H{C, Ci,C2, Bo,T',T",Com, B, D, K, 
Ci,C2,R',R",C',flC,b,K',L',ch) 


Send {Bk, E, H, IDy, DT) to TA in order to be saved 
within the secured database DBusedTickets'i IDy is 
the identity of the validator and DT is the date and 
time of the transaction. 


Fig. 7. The validation protocol 
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7.4 A secure Post-payment process 

One novelty of our m-ticketing protocol, in addition to 
the respect of users’ privacy, is to give the ability to 
charge a user after the usage of m-tickets. 

7.4.1 Regular reporting 

In a post-payment approach, the m-ticketing application 
must report unused m-tickets to the back-end server, 
before the pre-defined D day. Thus, the regular reports 
does not question the privacy of the user. The follow¬ 
ing example gives further clarification. Suppose that the 
user retrieved a permission token of 5 m-tickets. Be¬ 
fore D day, he used 4 m-tickets, i.e., m-tickets number 
1, 2, 3 and 4. On D day, the m-ticketing application 
will report to the back-end server the m-ticket number 
5 using a network connection. The report contains Bs 
= and the proof n = POK{k, s,r, A : B 5 = 

gP(s+5+l) ^ ^ ^ (^gfhy/h+r) ^ 5 ^ 

Regularly revealing the unused m-tickets enables 
the transport authority to (1) charge the user, (2) check 
the reliability and accuracy of the reports without ques¬ 
tioning the user’s privacy. Indeed, the unlinkability of 
user’s m-tickets (Bj, = , B, 11), both during 

the use of the service and during the reporting phase, 
is ensured owing to the q-DDHI and DDH assumptions 
(cf. unlinkabililty proof). 

7.4.2 Countermeasures 

A malicious user’s goal simply consists on not paying or 
paying less than what he is supposed to. To do so, he 
may try to block the reporting or attack the cardlet of 
the SIM. 

If the user blocks network communications in order 
to block reporting, the SIM cardlet will refuse to issue 
m-tickets for a permission token after reaching the limit 
of maxticket, or the limit of the time window controlled 
by V. This countermeasure C relies on the security of 
the SIM card. 

If the user performs a successful physical attack 
against the SIM card, which is extremely difficult |24| . 
he may try to (1) defeat the countermeasure C and 
never do reports, or (2) use the same m-ticket several 
times or (3) report a used m-ticket. This will be detected 
in DBusedTickets and TA can decide to break the user’s 
anonymity and retrieve all his m-tickets usage history. 


Thus, the user is forced to report his consumption 
and renew his permission token lest the service is unus¬ 
able or TA breaks his anonymity. 

Note that forging an m-ticket is not possible, even 
with a compromised SIM because of the unforgeability 
property. 

8 Security analysis 

We prove that our m-ticketing protocol provides the se¬ 
curity and privacy properties defined in Section |4.3| 
Theorem 4 (Non-frameability). Our m- 
ticketing protocol is non-frameable, in the random 
oracle model, under the q-DDHI assumption. 

The proof is detailed is Appendix 
Theorem 5 (Unforgeability). Our m-ticketing 
protocol satisfies the unforgeability requirement, in the 
random oracle model, under the q-SDH assumption. 
The proof is detailed is Appendix 
Theorem 6 (Unlinkability). Our m-ticketing 
protocol satisfies the unlinkability requirement, in the 
random oracle model, under the q-DDHI and DDH as¬ 
sumptions. 

The proof is detailed is Appendix 

9 Performance results 

We implemented the user side of our solution on a SIM 
card and the validator side in a regular PC (cf. Ap¬ 
pendix]^. We used a 256-bit Barreto-Naehrig curve [1] 
over Fg since this family of curves provides an optimal 
size for Gi and G 2 while preventing the MOV attack m 
due to their embedding degree of 12. Gi is the group of 
Fg - rational points of order p and G 2 is the subgroup of 
trace zero points in B(Bgi 2 )[p]. Our pairing is of type- 
3 |29| . More details are given in Appendix jp] 

Pre-computations. The pre-computations for 
preparing one signature occurs in 1.7 s. It consists in 
computing elements involved in proving that the user 
knows a valid signature on his secret s. The total size of 
the elements that the card has to store for one signature 
is 1130 bytes (24 Zp elements, 10 compressed points and 
one digest output). 

Validation phase. Table gives timings (average 
over 50 trials and standard deviation between parenthe¬ 
ses) for the whole validation protocol which includes the 
validator authentication, the signature generation and 
an m-ticket verification. The timings include as well the 
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Validator 

Card Signature 

Verification by PC 

Total 


authentication 

-F NFC connection 

(1) without pairing 

(2) with pairing 

(1) 

(2) 

Battery-On 

Battery-Off 

56,98(0.70) 

76.55(7.46) 

123.01(3.24) 

185.28(18.68) 

4.43(1.32) 

12.19(3.20) 

184.25(3.43) 

266.52(17.91) 

191.80(4.73) 

272.55(25.73) 


Table 2. Timings of m-ticket validation protocol including validator authentication (ms) 


NFC exchanges duration. We denote by “Battery-Off” 
a powered-off phone either by the user, or because the 
battery is flat. In this situation, as stated by NFC stan¬ 
dards, NFC-access to the SIM card is still possible, but 
with degraded performances. 

Regarding the validator authentication, we chose to 
use RSA with a 1984 bits key (this is the greatest size 
supported by the SIM card) and a short public verifi¬ 
cation exponent v (v = 65537). The validator asks the 
card for a challenge {RCy)- Then, he sends back his 
response to this challenge, his own challenge {ch) (32 
bytes) and the current date {TS) (6 bytes). 

The column “Card signature” gives the duration of 
real-time computations of a signature (computing an m- 
ticket Bk, E and 11) and the NFC communication time. 
The considered operations for generating the signature 
are only one hash value and lightweight operations in 
Zp. The size of the computed signature is 778 bytes (sent 
by 4 APDUs). Regarding the communication between a 
SIM card and a reader, it is slow (> 85 ms), but the 
whole process (Signature+NFC) remains very fast, i.e., 
123.01ms on average. 

For the signature verification by the validator, we 
distinguish two cases: the validator holds the private 
signature keys (y, 7 ), or not. The extra pairing com¬ 
putations performed in the second case do not add an 
important delay to the verification because a regular 
desktop PC can efficiently achieve such computations. 

In total, the m-ticket validation occurs for the first 
case (without pairing at the verifier side) in 184.25 ms 
on average and in 191.80 ms for the second case (with 
pairing at the verifier side). When the battery is flat, 
the validation occurs in at most 272.55 ms on average. 

10 Conclusion 

In this paper, we proposed various cryptographic en¬ 
hancements: (1) optimizations of BB-signature schemes 
and ( 2 ) a new set-membership proof that does not re¬ 
quire pairing computations at the prover side. These 
contributions enable to design efficient protocols over 


NFC. Then, based on these cryptographic primitives, we 
designed a secure m-ticketing protocol that prevents a 
malicious transport authority from linking users’ trips. 
Moreover, as the entire computations are done within 
the SIM card, we enhance the user’s privacy with re¬ 
gards to a compromised smartphone. Owing to regu¬ 
lar reports of unused m-tickets, the user is able to se¬ 
curely post-pay for his m-tickets without disclosing any 
information about the performed trips. Moreover, we 
planned countermeasures against m-ticket cloning and 
multiple usage. Finally, we prove that our protocol is 
completely off-line and efficient: the validation occurs 
in 184.25 ms and in 266.52 ms when the battery is flat. 
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A Privacy weakness of Rupp et 
al. protocol 

In the following, we give further details about the pay¬ 
ment protocol for public transport proposed by Rupp 
et al. at FC 2013 [H]. Then, we present an attack that 
enables a malicious transport authority to break users’ 
privacy. 

At first, the user buys a trip authorization token 
{TATi) which consists of an (extended) coin in Brands’ 
scheme |52| . This token enables the user to perform one 
trip. Then, the user receives a fresh refund token {RT = 
SNjiT such that SN^t ■<— G), sets a variable i? to 1 
and u to 0. R will be used to aggregate blinding factors 
and V is the refund amount. At the entry turnstile, the 
user shows a TATi and proves its ownership. Right after 
this, the user receives a refund calculation token {RCT) 
which consists of a MAC on TAT, a timestamp and the 
reader ID. At the turnstile of the exit, the user shows his 
RCT and proves the ownership of the TAT contained 
within it. In addition, he collects refund on his RT, as 
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Collecting Refund 

User 

Exit turnstile 

r <— Z* 

< - - - Determine the refund uj 

based on the received 

information in RCT 


RT' = RT'’ 

RT' 

- 

V = V + Ul, 

R = Rr mod p, 
RT = RT" 

<- — - RT" = RT"^" (1) 

Redeeming Refund 

User 

Transport authority 

r ^ z;, RT' = 

RT'', 

R = Rr mod p 

-^ check validity of 


V < p — 1, 


e{SNgp,hd'') = e{RT',h) (2) 


Fig. 8. The refund protocols of Rupp et a I. ED 

described in Figure A refund value ui is represented 
as a tu-times BLS signature m SN'^rp such that d is 
the secret BLS signature key of the transport authority. 
Later, the user redeems his RT. This consists on sending 
a blinded version of his RT {RT' = RT''), SN^t, R 
and the collected amount v to the transport authority. 
The latter checks the validity of both SNrt and the 
signature: 

e{SN^T,h‘^^) = e{RT',h) (3) 

In HD, Rupp et al. assume that, for efficiency reasons, 
users don’t verify their RTs. Indeed, verifications of re¬ 
fund tokens (step 1 in Figure]^ is too costly and can not 
be handled by constrained devices such as SIM cards. 
This lack of verification could lead to serious privacy 
weaknesses: a malicious transport authority could link 
users’ trips. 

More precisely, for a given station, the transport au¬ 
thority is able to identify all the users who left at this 
station. To this end, in step (1) in Figure instead 
of computing RT" = RT''^ , the transport authority 
chooses a variable t hp and computes RT"=RT'^‘^ . 
The user will not detect that RT" is improperly calcu¬ 
lated because there is no verification on the user’s side. 
The refund token RT will then carry on the exponent 
t till the redeeming refund step, i.e., RT' = 
where j corresponds to the number of times the user 
left the targeted station, R is the product of all the 
variables r and v is the sum of all the refunds ui. At the 
redeeming refund step, upon receiving the serial num¬ 
ber SNrt, the blinded version of the refund token RT', 
the refund amount v, and the aggregate blinding factor 
R, the transport authority will as usual check the va¬ 


lidity of SNrt and whether the amount is within the 
allowed range [0,p— 1]. Now, in order to verify the sig¬ 
nature and distinguish users who exited at the relevant 
station, the transport authority starts by checking the 
relation ]§. If equation ([^ holds, this implies that the 
user did not left the targeted station. Otherwise, the 
transport authority checks: 

e{SNt^,h‘^^) = = 

e{SNi^'^\h) = e{RT',h) (4) 

To do so, the transport authority will repeat the compu¬ 
tations with different values of j until the relation (41 
holds. When e{SN^rP’, h'^ ) = e{RT',h) equation (4| 
holds, this implies that the user left the targeted sta¬ 
tion j times. 

In order to monitor several stations at the same 
time, the transport authority will have a list of vari¬ 
ables t, e.g., tA for station A, ts for station B, etc. At 
the redeeming refund step, the transport authority will 
test different values of t until it finds the ones that sat¬ 
isfy the relation 

e(S'Arn‘"“^, I e{RT', h) (5) 

where characterizes a station x and jx represents the 
number of exits at the station x. For instance, if the 
user left the station A four times, the station B twice 
and the station M once, relation © will be as follows: 

) = e{RT',h). In this way, the trans¬ 
port authority will be able to identify the users that left 
a pool of targeted stations but also the number of times 
they exited at these stations: this clearly implies that 
users’ trips are linkable. 

However, solving relation © and finding the right 
tuples {tx,jx), becomes quickly a complex and unman¬ 
ageable task when the number of targeted stations in¬ 
creases (more than three for example). To mitigate this, 
a malicious transport authority could only monitor two 
stations at the same time and periodically change these 
monitored stations. In this way, the transport author¬ 
ity will be able to monitor a large number of stations 
and will have a global overview of the users’ journeys 
which breaks the privacy property of Rupp et al. system. 
We would like to emphasize that privacy holds in P4R 
(Rupp et al. system |44| ~) if we assume that the transport 
authority is “honest but curious”, i.e., it will not deviate 
from the refund protocol, but such an assumption is too 
strong in the context of transport systems |54| . 

In order to mitigate this issue, the user should check 
the received refund (Step (1) in Figure]^. This verifi- 
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cation implies pairing computations. However, in con¬ 
straint environments such as the SIM card, this is not 
feasible yet. A straightforward solution would be to del¬ 
egate these computations to the smartphone. Such a 
solution has two main drawbacks. On the one hand, 
delegating computations to an untrusted environment, 

i.e., the smartphone which could be compromised by 
spywares, will affect the user’s privacy. On the other 
hand, verifying the received refund token would lead to 
inefficient transactions at exit turnstiles. 


B Proof of Theorem 2 

Sketch of proof. The completeness of the protocol 
follows by inspection. The soundness follows from the 
extraction property of the underlying proof of knowl¬ 
edge and the unforgeability of the underlying signature 
scheme. In particular, the extraction property implies 
that for any prover P* that convinces V with probabil¬ 
ity e, there exists an extractor which interacts with P* 
and outputs a witness {k,v,l) with probability poly(e). 
Moreover, if we assume that the extractor input consists 
of two transcripts, i.e., {Y, Com, B, D, c, c, si. Si, S 2 , 
52,53,53}. The witness can be obtained by computing 
(all the computations are done mod p): I = (53 —S3)/(c— 
c) and fe = (si - Si)/(c - c)-, v = (52 - S 2 )/(c - c); 

The extractor succeeds when (c — c) is invertible in 
Zp. If the following check D = holds , this implies 
that: D = B^ = B\g^. Therefore, B^B^ = gK Let us 
denote by Ak = B^^K Note that we necessarily have 
I ^ 0, otherwise this would imply that the prover knows 
the secret value y (which would be equal to —k mod p). 

We therefore have = g and consequently that 

Afc = g^Av+k)^ gQ prover knows a valid BB-signature 
on the value k. This implies that fe G <I>. 

Also note that it D = B^ then this implies that the 
Prover P only knows one representation of D in the base 
B\ and g. Otherwise this would imply that P knows 
the private key y. Indeed, suppose that P knows two 
representations of D in the base Bi and g. Let us denote 
by {k, 1) and (fc, 1) these two representations. Since Gi is 
a prime order group and Bi ^ I and g ^ I, this implies 
that k ^ k and I ^ 1. Since D = B\g^ = Big^, this 
implies that B^~^ = g^~^ and that _ g 

us denote hy y = {k — k)/{l — l). Then D = B^ = B^g^ = 
B~^B~^^yK Since G\ is a prime order group this implies 
that y = —k — ly. 

If A: ^ <I>, then P* can be directly used to mount 
a weak-chosen attack against the BB-signature scheme 


with probability poly(e) of succeeding. Thus e must be 
negligible. 

Finally, to prove (honest-verifier) zero- 
knowledge, we construct a simulator Sim that will 
simulate all interactions with any (honest verifier) V*. 

1 . Sim retrieves Y and ^ from V*. 

2 . Sim randomly chooses A: G <I> and I G Z* and com¬ 
putes B = A\ , Bi = 5 ^“^^ and D = B\gK 

3 . Sim randomly chooses c, 51,52,53 G Z* and com¬ 
putes Comi = gl^hjiCom~‘^ and Di = B^^g^^. 

4 . Sim outputs S = {Com, B, D,Comi, Di,c, si, S2, 
S3}. 

Since Gi is a prime order group, then the blinding is 
perfect in the first two steps and S and I 4 *’s view of the 
protocol are statistically indistinguishable. 


C Proof of Theorem 3 

Sketch of proof. The completeness follows by in¬ 
spection. 

Soundness: roughly speaking, the whole proof H 
can be divided in three sub-proofs Hi, II 2 and Hs, where: 
Hi = POK{a,s,r,r 2 ,r 3 ,r 5 ,a:C = g^ xh'^xB’'^ hT’ = 
GSH^2 ^ ^ ^Cl = g^ ^C2 = 

gi X h^) 

n 2 = POK{k,v,s,r 2 : Com = g'[h^ AT' = A 

K = g,B-^ = '=) 

U 3 = POK{k, V, I : Com = g'{h^ AD= B^g^) 

If the verifier accepts the proof H this means that: 
D = By (1) and C = B{{ (2). 

Note that the proofs Hi, II 2 and 03 are classical 
variants of Schnorr’s proof of knowledge. Using the “ex¬ 
tractors” of these proofs of knowledge, we can retrieve 
k, a, s, r, 1 . 

From (1) we have: D = = B^gK This implies 

that B^B'^ = g'. Let us denote by Aj, = B^^'. (Note 
that I 7 ^ 0 , otherwise this would imply that the prover 
knows the secret value y). We therefore have A^^^ = g 
and therefore that A^ = g^Av+k)^ gg ^j^g plover knows 
a valid BB-signature on the value k. This implies that 
k G [l..maa;ticfcet]. 

From (2) we have that C = Bq = x /i“ x B^”. 
This implies that Bq^” = 5 “® x /i“. Let us denote by 
A = Bq^“, this implies that = gf x h (Note that 

a 7 ^ 0 , otherwise this would imply that the prover knows 
the secret value 7 ). So A = (gf/i)^/*''’''''”^. The prover 
therefore knows a valid permission token (A, r, s). 
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In conclusion, the prover knows a permission to¬ 
ken {A,r,s) and a value k such that 
k G [l..maxticket\ and E = {Ci,C 2 ) is an El Gamal 
encryption of gf. 

(Honest-verifier) Zero-Knowledge: since Hi, 
112 and Ha are classical ZKPK, we can easily con¬ 
struct simulators Siml, Sim2 and Sim3 (respectively) 
for such proofs. From these simulators, it is straightfor¬ 
ward to construct a simulator Sim that will simulate all 
interactions with any (honest) verifier V*. Since Gi is a 
prime order group, then the blinding would be perfect 
and the output of Sim and E*’s view of the protocol 
would be statistically indistinguishable. 

D Platform and implementation 
details 

D.l SIM card details 

We used Javacard 2.2 for developing all the crypto¬ 
graphic computations into the SIM card. In particular, 
the SIM card has access to the functions handling el¬ 
liptic curves operations. The SIM card handles requests 
from the validator using the NCF contactless interface. 

D.2 Validator details 

The validator has been developed in Java and Scala. 
The Java software uses a native library for EC scalar 
multiplications and pairings. This library depends on 
libGMP for big integers computations and benefits from 
its assembly optimizations. Furthermore, computations 
are distributed between threads (at JVM level) to bene¬ 
fit from the multi-core architecture of the PC. The PC is 
an Intel(R) Xeon(R) with a E5-1620 CPU with 4 cores 
running at 3.70GHz under a 64-bit Linux OS. The NFC 
reader of the validator is an Omnikey 5321 dual inter¬ 
faces. 

D.3 Curve and Pairing Parameters 

The curve and pairing parameters that we used in the 
implementation of our m-ticketing system are: 

q = 8243401665430090752057404098378368203946728292799613002 
4655912292889294264593 

p = 8243401665430090752057404098378368203918016968090658713 
6896645255465309139857 
b = 5 


E Security proofs 

E.l Preliminaries 

Discrete Logarithm (DL). For any multiplicative 
group G of prime order p, the DL assumption states 
that given a random generator g £ G and a candidate 

Y G G, it is hard to find an integer y mod p such that 

Y = gy. 

One-more Discrete Logarithm (OMDL) [2]. 

For any multiplicative group G of prime order p, the 
OMDL assumption states that given a random genera¬ 
tor p G G, a challenge oracle that produces a random 
group element Yi when queried and a discrete logarithm 
oracle (with respect to g), it is hard to find, after t 
queries to the challenge oracle (where t is chosen by the 
adversary) and at most t—\ queries to the discrete log¬ 
arithm oracle, the discrete logarithms of all t elements 
Y. 

q-Strong Diffie-Hellman I (q-SDH-I). For any 

multiplicative group Gi of prime order p, the q-SDH-I 
assumption states that given three random generators 
{go, pi, /i)g Gi, a value W' = Pq, an oracle O that on 
input a value s £ Zp outputs a pair (r, A = 
with r G Zp , it is hard to output a new triplet 
{r\s',A' = (pf with {r',s') G Zp such that 

s' has never been queried to O. 

Lemma 1. If the q-SDH assumption holds in Gi 
then the q-SDH-I assumption holds in Gi. 

Proof. See [ 58 ] for a proof of this Lemma. 

Remark: The triplet {r',s',A') corresponds to a 
permission token of our m-ticketing protocol. In the se¬ 
quel, we will call the oracle O, a BB-signature oracle 
and the value s' the (permission) token secret. 

Forking Lemma. We use the Forking Lemma | 43 | 
in our proofs, to prove that an adversary A is not able 
to produce a new valid m-ticket Tick^ (respectively a 
Schnorr’s signature p, see Figure 6 ) unless he knows 
all the underlying secrets (a, s, r, A, k) (respectively the 
secret xu)- 

Using the notation of | 43 | . if an adversary is able to 
produce a valid ticket Tickk (fc, cti, h, <72) where 
ui=(G, Gi, G2, Bo, T', T", Com, B, D, K, c[, C'2, R!, 
R", C', T4, Gomi, Do, K', L' , ch), 
h=H{C, Cl, C2, Bo, r, T", Com, B, D, K, C'l, C'2, 
R!, R", G', tI, Gotoi, Di, K', L', ch) and 
a’2 = (si, S2, S 3 , wi, UJ2, ..., W12), 

then it can produce two valid m-tickets {k, ai, h, <72) and 
(fc, ( 7 i, h', (72) such that h A h'. 


A Practical Set-Membership Proof for Privacy-Preserving NFC Mobile Ticketing 


21 


E.2 Proof of non-frameability 

Sketch of proof. We assume that the challenger C 
in the experiment (I"'') receives a random in¬ 
stance 9^‘) of tho one-more DL problem 

where g is a random generator in Gi. C will run the ad¬ 
versary as a subroutine and act as .4’s challenger in 
the non-frameability experiment. Because C is against 
the one-more DL assumption, he has access to a DL or¬ 
acle. C picks three random values ^2 and ^3 in Zp and 
computes gi = 9u = 9^^ and G = gf^. The other 
generators of the m-ticketing system are randomly cho¬ 
sen. A chooses the keys tsk for the transport authority 
and rsk for the revocation authority and C chooses the 
key skup for the Paillier encryption scheme. C is there¬ 
fore able to construct the public parameters pp for A 
and can answer to its requests in the following way: 

- ORegisternu requests: C answers using his input of 
the one-more DL problem. C puts hui = {g^')^^= g^ 

- ORegistevMU requests: C does not need to do any¬ 
thing. 

- OCorruptUser requests: C uses is DL oracle to give 
the corresponding Xi to the adversary. 

- OTokenRequestu requests: C first uses his input of 

the one-more DL problem to compute the commit¬ 
ment Com: C puts Com= g^’. If the pro¬ 

tocol does not abort then we put s=Xj+S2 mod p 
and c = gf, where Xj is unknown to C and S 2 is pro¬ 
vided hy A. In the random oracle model, C is able 
to perfectly simulate the proof of knowledge IIi as 
well as the Schnorr’s signature p. 

- OGenTicket(IDu, view) requests: All the values in¬ 
volved in the computation of an m-ticket Tickk can 
be easily simulated by C except T' and B^- To com¬ 
pute T' = G^ where r 2 is a random value chosen 
by C, it proceeds as follows: T' = {Com x 

= As C does not know the value s it can¬ 
not compute or simulate the value Bk = ■ 

It will therefore choose a random value R and de¬ 
fine Bk as R. In the random oracle model, C can 
simulate the proof of knowledge 11 using standard 
techniques. The simulation is not perfect since we 
replace the value Bk by a random value R. However 
A will not detect this change unless he can solve the 
q-DDHI problem. 

- OReportTicket{IDu, view) requests: C proceeds as 
in an OGenTicket request for each unused m-ticket. 

Now, we assume that the adversary A manages to pro¬ 
duce a valid m-ticket Tickk such that it breaks the non- 
frameability of our m-ticketing protocol and it mades t 


requests to the OC orruptU ser oracle. This means that 
this m-ticket has not been obtained on a OGenTicket 
query and the IdentUser algorithm on Tickk outputs 
an identifier I Du which is in 'HU along with a Schnorr’s 
signature p that proves that this m-ticket comes from a 
permission token obtained by this useij^ . 

It follows from the Forking Lemma that if A is able 
to produce a valid m-ticket Tickk (fc, cri, h, 02 ) where 
ai=(G, Gi, G 2 , Bo, T', T", Com, B, D, K, c[, C'^, R!, 
R!', C', T 4 , Gomi, Di, K', L' , ch), 
h=H{C, Cl, C 2 , Bo, T', T", Com, B, D, K, C'l, C'^, 
R!, R”, C', Ti, Comi, Di, K', L' , ch) and 
o' 2 =(si, S2, S 3 , wi, W 2 , ..., W 12 ) then it can produce two 
valid m-tickets (fc, cri, h, 02) and (fc, ai, h', 02) such that 
h A h'. Using the technique of replay and the soundness 
property of the proof H, one is able to extract all the 
secret values (o, s, r. A, k). 

First case: the value s corresponds to a permission 
token obtained during an OTokenRequestu on IDut 
(i.e., gf is equal to the value c produced during such 
a request). C outputs the t values Xi that comes from 
the requests to the DL oracle plus the value Xj = s — 
S 2 mod p and so breaks the one-more DL assumption. 

Second case: the value s does not correspond to a 
permission token obtained during an OTokenRequestu 
on IDui (meaning that all the values c generated dur¬ 
ing such requests are different from g®). We know by the 
definition of the experiment that no OC orruptU ser or¬ 
acle query (and consequently no DL oracle query) has 
been made on this identity. Therefore the public key 
hui corresponding to IDut is in the one-more DL prob¬ 
lem input. It follows from the Forking Lemma that if 
A is sufficiently efficient to produce such a signature p, 
then there exists an algorithm A’ which can produce 
two Schnorr’s signatures with non-negligible probabil¬ 
ity. Using the techniques of replay and soundness, C is 
able to extract the private key xu used to generate the 
signature p. C outputs the t values Xi, coming from the 
requests to the DL oracle, plus the value xui and so 
breaks the one-more DL assumption. 

We prove the non-frameability under the q-DDHI 
and one-more discrete logarithm assumptions |2]. We 
use in fact the OMDL assumption to get a better reduc¬ 
tion, but the proof can also be done under the discrete 
logarithm assumption. As the q-DDHI assumption im¬ 
plies the DL one, we can conclude that our m-ticketing 


4 We would like to emphasize that since the output of IdentUser can 
be publicly verifiable, a wrong IdentUser procedure is statistically 
negligible (even for a powerful adversary). 
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protocol is non-frameable, in the random oracle model, 
under the q-DDHI assumption. 

E.3 Proof of unforgeability 

Sketch of proof. Let A be an adversary who breaks 
the unforgeability requirement of our m-ticketing pro¬ 
tocol with non-negligible probability. We will construct 
an algorithm B, using A as an oracle, which breaks the 
q-SDH-I assumption. B receives on input from its chal¬ 
lenger (Gi, go, gi, gu h, W' = g^) the public parame¬ 
ters of the q-SDH-I challenge and has access to a BB- 
signature oracle. The other generators of the m-ticketing 
system are randomly chosen. 

B also chooses the keys for the Paillier encryption 
scheme. It sends W' and the public key of the Paillier 
scheme to A. The private and public keys of the El 
Gamal cryptosystem can be chosen either by A or B. B 
is therefore able to construct the public parameters pp 
for A and can answer to its requests as follow: 

- ORegisternu requests: B randomly chooses Xu G 
Zp and computes hjj = g^ . 

- ORegisterMU requests: B does not need to do any¬ 
thing. 

- OCorruptUser requests: B gives xu to A. 

- OTokenRequestr requests: B plays as follows: B 

first receives a Paillier encryption Co- It decrypts it 
(recall that B chose the private key for the Paillier 
encryption scheme) and retrieve the corresponding 
plaintext si. It then queries the BB-signature oracle 
on s where s = si + S 2 and S 2 is randomly chosen 
by B. The BB-signature oracle sends back a pair 
(r, A = with r G Zp , and B trans¬ 

mits it to A along with the value S 2 . So H perfectly 
simulates the OTokenRequestr for A. 

- OGenTicket{IDu,view) requests: since B knows 
the values of all the tokens {A, r, s) that have been 
issued during OTokenRequestr requests, it can eas¬ 
ily answer to OGenTicket queries. The simulation 
of this oracle is perfect. 

- OReportTicket{IDu, view) requests: B proceeds as 
in an OGenTicket request for each unused m-ticket. 

We differentiate two types of adversaries: 

- Type-1 Forger: an adversary that outputs a valid 
m-ticket Tickk which cannot be linked to a regis¬ 
tered user (corrupted or not). 

- Type-2 Forger: an adversary that outputs more 
valid m-tickets than he obtained. 


We show that both Forgers can be used to solve the 
q-SDH-I problem. However, the reduction works differ¬ 
ently for each Forger type. Therefore, initially B chooses 
a random bit Cmode G 1, 2 that indicates its guess for the 
type of forgery that B will output. 

If Cmode = 1: Eventually, B outputs, with 

non-negligible probability, a valid m-ticket Tickk' = 
(Bfc/, E',11') such that the algorithm IdentUser, on the 
input Tickk', returns an unknown identifier ID (i.e., 
does not appear in DBueg)- 

First case: c = gf (the plaintext encrypted in E') 
has been queried during an OTokenRequestr request 
but no corresponding signature g, has been produced. 
This means that the adversary did not receive the value 
S 2 (where s' = s'l + S 2 ) from the OTokenRequestr or¬ 
acle. We know from the Forking Lemma and the proofs 
H and Hi that A necessarily knows s' and S 2 - Since 
only gl^ has been revealed by this oracle during the 
OTokenRequestr, A could be used to extract Discrete 
Logarithms. Therefore under the DL assumption, this 
first case could only occur with negligible probability. 

Second case: E' is an encryption of a commitment 
c = gf of a value s' that has not been queried during a 
OTokenRequestr request. Therefore s' has not been 
queried to the BB-signature oracle either. Using the 
Forking Lemma and the soundness property of the proof 
Hi, H is able to extract with non-negligible probabil¬ 
ity the secrets {a', s',r', A',k') underlying the m-ticket 
Tickk' ■ B outputs the triplet (r', s', A') to its challenger 
of the q-SDH-I assumption and therefore breaks it. 

If Cmode = 2: Eventually, A outputs, with non- 
negligible probability L = N x maxucket + 1 valid m- 
ticketsr {Tzcfc^. ’ where N is the number of calls to 

the OTokenRequestr oracle, maxucket is the number of 
authorized m-tickets by token and Tick^^. = {Bkj, E,Il). 
Let us denote by (si, S 2 , •.., sn) the iV token secrets 
submitted to the BB-signature oracle. W.l.o.g, we may 
assume that all these values are different (recall that 
a token secret s is jointly computed by A and B). We 
therefore have N x maxucket distinct token pairs {si, k) 
with i G {1,..., A^} and fc G {1,..., maxucket}- Let F be 
the set containing all these token pairs and Tick) the 
m-ticket corresponding to the token pair {si,j). 

Among the L m-tickets output by A, there is at 
least one m-ticket Tickk* for which the corresponding 
token pair (s*, k*) does not belong to F. Otherwise 
this would mean that two m-tickets among these L m- 


5 Without loss of generality, we do not make any distinction be¬ 
tween a ni-ticket and an unused m-ticket 
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tickets, e.g., Tickk^ and Tickk^, have the same token 
pair (since L > N x maxucket)- Let us denote by (si, 
fci) (respectively (s 2 j ^ 2 )) the token pair correspond¬ 
ing to Tickk^ (respectively Tickk^)- Therefore the se¬ 
rial number of Tickk^ would be equal to the 
one of Tickk,-. Bl = g^si+k.+i) ^ 

This case cannot occur since all duplicates (i.e. m-tickets 
which have the same serial numbers) are discarded in 
the experiment Exp(^"-^°’^®( 1 '^). 

Suppose now that s>t! G {si, S 2 , , Sjv}- Since 

{s*,k*) ^ r this implies that k* ^ { 1 ,, maccticfeet}- 
Such a case will happen with negligible probability un¬ 
der the q-SDH assumption (see Theorem 2). There¬ 
fore s>t! ^ {si, S 2 ,..., Sjv} and consequently has not 
been queried to the BB-signature oracle (-4 is in fact a 
Type-1 Forger). B then picks a random m-ticket Tickk' 
among the L m-tickets output by A. With probability 
1/L, it has chosen Tick^*- Using the Forking Lemma 
and the soundness property of the proof If, B is able 
to extract with non-negligible probability the secrets 
{a , s',r', A',k') underlying the m-ticket Tickk'- B out¬ 
puts the triplet (r', s', A') and therefore breaks the q- 
SDH-I assumption with non-negligible probability ^/L. 

To complete the proof, we need to clarify why we 
discard duplicates in Exp)^"'^°'^®(l'’'). We consider that 
Tickk = {Bk,E,Il) and Tickk' = {Bk'^E',11') are dupli¬ 
cates if their serial numbers are equal. Let us denote by 
(s,fc) (respectively {s',k')) the token pair correspond¬ 
ing to the ticket Tickk (respectively Tickk')- Since Bk 
= Bk' , we have s k = s' k' mod p- 

First case: (s, k) = {s', k'): This implies that Tickk 
and Tickk' are in fact the same tickets. We can therefore 
discard one of them. 

Second case: (s, fc) 7 ^ {s',k')'- 
Case 2-1: s or s' ^ {si, S 2 , ■■., Sjv}- This implies that 
is a Type-1 Forger. Under the q-SDH-I assumption, 
this case will occur with negligible probability. 

Case 2-2: s and s' G {si, S 2 ,..., sjv}. This implies 
that k and k' G {1,..., maxucket}- Otherwise A could be 
used to break the q-SDH assumption (see the proof of 
Theorem 2). Since s and s' have been randomly chosen 
(they are jointly computed by A and H), the probability 
that s + k = s' + k' mod p is negligible. Therefore Case 
2 . 2 . will occur with negligible probability either. 

Consequently, under the q-SDH assumption, only 
the first case could occur and we only discard tickets 
that come from the same token secret. 


E.4 Proof of unlinkability 

Sketch of proof. We prove the unlinkability under 
a slightly weaker model than the one presented in Sec¬ 
tion |4.3.3[ Indeed, we consider a slightly different ex¬ 
periment in which the adversary cannot query the re¬ 
vocation oracle OldentUserx- We rename this new re¬ 
quirement Unlinkability*. We would like however to 
emphasize that the access to revocation functionalities 
will likely be carefully controlled in a real deployment 
of an m-ticketing system. Therefore, unlinkability* is a 
reasonable model to consider. 

Anyway, in order to satisfy the original unlinkabil¬ 
ity requirement, we just need to replace the ElGamal 
encryption scheme, which only satisfies IND-CPA se¬ 
curity, by an 1ND-CCA2 encryption scheme. It is well- 
known that by double encrypting the same message un¬ 
der an IND-CPA scheme and using a simulation sound 
proof of equality of plaintexts, we obtain an 1ND-CCA2 
scheme. Therefore, by using the double ElGamal en¬ 
cryption scheme, which was proved 1ND-CCA2 in [53], 
our m-ticketing protocol would satisfy the original un¬ 
linkability requirement. 

Let A be an adversary who breaks the unlinkabil¬ 
ity requirement of our m-ticketing protocol. W.l.o.g. we 
will consider that a query to the OReportTicket ora¬ 
cle on {IDu, view) for the report of j unused m-tickets 
is equivalent to j queries to the OGenTicket on {IDu, 
view)- 

Let m = maxticket- We will say that an adversary 
A against our unlinkability experiment Exp)^"**"*^~^(l^) 
is a Type-(i, j) distinguisher, with i < m — 1 and 
j < m — 1 , if ^ after having received its challenge 
(from its Exp(^”**"^“^(l^)-challenger) makes at most i 
queries to the OGenTicket oracle on (io, viewo) and 
j queries to the OGenTicket oracle on {ii, viewi)- 
We can remark that a Type-(i, j) distinguisher, with 
i < m — 1 and j < m — 1, is also a Type-(m — 1, 
m — 1) distinguisher. We may therefore, without loss 
of generality, restrict our attention to Type-(m — 1, 
m — 1) distinguishers. In the sequel, we will thus as¬ 
sume that A is such an adversary. More precisely, we 
will suppose that after receiving Tickk,, and Tickki_,,, 
A arbitrarily queries the O Register hu , O Register mu, 
OGorruptUser, OIdentTicketr and OTokenRequestu 
oracles and then queries the OReportTicket oracle on 
(to, viewo) and (ti, viewi). 

We give a security proof as a sequence of games, 
using Shoup’s methodology [55]. We will only give a 
rather high-level description of the initial game (Game 
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0 ) and brief descriptions of the modifications between 
successive games. 

Game 0: This is the original attack game with re¬ 
spect to a given efficient adversary A. 

The challenger C randomly chooses g, go, gi, gt, gr, 
gu, h, G, H nine generators of Gi and (72, gs two gen¬ 
erators of G2. It also chooses the keys for the Paillier 
encryption scheme as well as the ones for the transport 
authority and revocation authorities. C sends gpk and 
tsk to A. C answers to yi’s requests as follows: 

- ORegisternu requests: C randomly chooses Xu & 
Zp and computes hu = 

- O Register MU requests: C does not need to do any¬ 
thing. 

- OCorruptUser requests: C gives xu to A. 

- OTokenRequestu requests: C chooses a random 
value Si to obtain a valid permission token (A, r, s) 
and uses xu to generate the signature g. 

- OGenTicket{IDu, view) requests: C uses its permis¬ 
sion token (A, r, s) and a fresh index k that has 
not been used in a previous query of OGenTicket 
on I Du and view and computes a ticket Tickk = 
{Bk,E,U). 

- OldentTicketrilDujView) requests: C computes 
the m-tickets Tickk based on the secret s corre¬ 
sponding to the user identifier I Du and gives them 
to A. 

- OReportTicket{IDu,view) requests: C proceeds as 
in a OGenTicket request for each unused m-ticket. 

The adversary chooses two honest users io and ii 
and two indexes ko and ki. C runs the protocol 
TokenRequest with fo and ii and outputs the corre¬ 
sponding views, viewo and viewi, to A. It then gen¬ 
erates two valid m-tickets: Tickk,, = {Bkt, for 

io and Tickk^_,, = {Bk^_,,, Ei-b,Ui-b) for u and send 
them to A. The goal of A is to guess the value of 
b. After having received its challenge, A can queries 
the O Register HU, O Register mu, OGorruptUser, 
OTokenRequestu, OGenTicket, OldentTicketr and 
OReportTicket oracles but with the following restric¬ 
tions: it cannot query the OGorruptUser oracle on io 
or ii or the OIdentTicketr oracle on {io, viewo) or (n, 
viewi) and cannot query the OReport Ticket oracle on 
(fo, viewo) or (ii, viewi) if both users did not validate 
the same number of m-tickets (otherwise it can easily 
win this game). 

At the end of the game, the adversary outputs 
a bit b', its guess. Let So be the event that b = 
b' in this game and Si the event that b = b' in 


game i. We have: |Pr[S'o] — 1/2| = ^(1^) = 

|Pr[ExpX“"'=-^(l^) = 5] - 1 / 2 | 

Let {Tickl, = {Bl,EluIT^i)}]zT~" denote the 

'^b ^b 

m — 1 unused (reported) m-tickets of io and {Tick^., 

= (B^i , , n^i )yiZ'Z~^ the ones of ii, where the 

fcj’s and the k{_b’s belongs to { 1 ,... ,m}. 

- Game(0,b): This is the same game as Game 0 
except that we replace the El Gamal ciphertext Eb 
by an encryption of a random value and then simu¬ 
late the proof Iff,. Such a simulated proof can easily 
be done in the random oracle model using standard 
techniques. Under the DDH assumption, A cannot 
detect this change. Indeed, we can easily construct 
a DDH distinguisher V with DDH-advantage satis¬ 
fying: 


|Pr[Bo] -Pr[B(o. 6 )]| < Advg^"(l^) ( 1 ) 
where Advp^^(l^) is the DDH-advantage of V 
in solving the DDH problem. In the sequel, we 
will use the simplified notation Adv ddh (respec¬ 
tively Ad-Vq-DDHi) to denote the DDH-advantage 
(respectively the q-DDHI advantage) of some effi¬ 
cient algorithm in solving the DDH (respectively q- 
DDHI) problem. 

Game(0,l-b): This is the same game as 
Game(0,b) except that we replace the El Gamal 
ciphertext Ei-b by an encryption of a random value 
and then simulate the proof Hi-j. Such a simulated 
proof can easily be done in the random oracle model 
using standard techniques. Under the DDH assump¬ 
tion, A cannot detect this change. Indeed, we can 
easily construct a DDH distinguisher D with DDH- 
advantage satisfying: 


|-P^[>S'(0.6)] - -P?’[>S'(0,1-6)]| < AdVDDH (2) 

- Game(0,0,b): This is the same game as 
Game(0,l-b) except that we replace the serial 
number Bk,, by a random value and then simulate 
the proof H;,. Such a simulated proof can easily 
be done in the random oracle model using stan¬ 
dard techniques. Under the q-DDHI assumption, 
A cannot detect this change. Indeed, we can easily 
construct a q-DDHI distinguisher V with q DDHI- 
advantage satisfying: 

|-P^['S'(0.1-b)] - -P’'[<S'(0.0,6)]| < AdVq-DDHI (3) 

- Game(0,0,l-b): This is the same game as 
Game(0,0,b) except that we replace the serial 
number Bk,^_,, by a random value and then sim¬ 
ulate the proof Hi-f,. Such a simulated proof can 
easily be done in the random oracle model using 
standard techniques. Under the q-DDHI assump¬ 
tion, A cannot detect this change. Indeed, we can 
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easily construct a q-DDHI distinguisher V with q 
DDHI-advantage satisfying: 

|-P’'[5'(0.0,6)] - -P’'['S'(0.0,l-6)]| < Ad-Vq-DDHI ( 4 ) 

Let Game 1 be the same game as Game(0,0,l-b) 
Combining (1), (2), (3) and (4), we obtain: 

|L’r[S'o] — Pr[5'i]| < 2AdrvDDH + 2AdVq-DDHi 

We then proceed similarly for each unused m-ticket 
of *0 and ii: {Tick^ = {Bl^, and 

{Tickle = {Bl El For * = 1 

to m — 1 , we define the following game. 

- Game(i,b): This is the same game as Game i 
= Game(i-l,0,l-b) except that we replace the El 
Gamal ciphertext El by an encryption of a random 
value and then simulate the proof 11 ^. 

- Game(i,l-b): This is the same game as 
Game(i,b) except that we replace the El Gamal 
ciphertext by an encryption of a random value 
and then simulate the proof 

- Game(i,0,b): This is the same game as Game(i,l- 
b) except that we replace the serial number by 
a random value and then simulate the proof Ii\. 

- Game(i,0,l-b): This is the same game as Game 
i,0,b) except that we replace the serial number 
Bli by a random value and then simulate the 
proof ni_h. 

Let Game i + 1 be the same game as Game(i,0,l-b). 
We obtain as above: |T’r[Si+i] — Br[Si]| < 2Ad'VDDH + 
2AdVq-DDHI 

Using our notation, Game m is the same 
game as Game(m-l,0,l-b). In the latter game, the 
unlinkability-challenger gives no information (in a 
strong information theoretic sense) to A about the bit b 
(since all the El Gamal ciphertexts have been replaced 
by encryptions of random values and all serial numbers 
have been replaced by random values). Therefore we 
have: Pr[Sm] = 1 / 2 . 

We can now give an upper bound for 

Adv“"'™'=-''(1^) = |Br[Exp7'*"'^-^(l^) = 5]-l/2| 
= |Pr[5o] -Pr[B 7 | 


\Pr[So] - Pr[Sm]\ < ^Z'^-^\Pr[Sq] - Pr[B,+i]| < 

2m X {AdvDDH + AdVq-DDHi) 

Therefore under the DDH and q-DDHI assump¬ 
tions, the advantage Adv7**"^~*(l^) of a Type-(m— 1, 
m — 1 ) distinguisher is negligible (and consequently the 
one of a Type-(f, j) distinguisher, with i < m — I and 
j < m — 1 , is also negligible). 

We can then conclude that our proposed m-ticketing 
protocol satisfies the unlinkability* requirement, in the 
random oracle model, under the DDH and q-DDHI as¬ 
sumptions. 


We have: 



